Situation Professionnelle : Gestion des sauvegardes et de la résilience
Compétences du référentiel visées :
-
1.4 : Vérifier la continuité
- Justification : Mise en place et test d’une procédure de restauration complète permettant de garantir la reprise du service GLPI dans le respect du RTO.
-
1.5 : Gérer les sauvegardes
- Justification : Déploiement d’une solution de sauvegarde automatisée (base de données et fichiers) avec gestion de la rétention et respect des objectifs de RPO et création de différentes archives.
Compétences techniques mobilisées :
-
Utilisation avancée de GLPI (Moteur de règles, Gabarits, Catalogue de services, Journaux, Niveaux de services, Calendriers, ...)
-
Modifications de fichiers sur Linux pour les logs
-
Utilisation du référentiel ITIL
Contexte et Objectifs :
Dans le cadre de la fusion entre Solutech et Horizon, une CMDB complète a été mise en place, centralisant des données critiques pour le support. Sa perte ou son indisponibilité compromettrait fortement l’activité de l’entreprise.
L’objectif est donc de sécuriser ces données en définissant une stratégie de sauvegarde fiable, basée sur les notions de RPO (perte de données admissible) et RTO (temps de coupure toléré), ainsi que sur la règle 3-2-1 afin d’assurer la résilience du système.
Enfin, la solution doit garantir la traçabilité des actions via des comptes nominatifs et être validée par des tests de restauration, afin de certifier la fiabilité des sauvegardes et d’assurer une reprise efficace en cas d’incident.
Besoins identifiés :
-
Assurer la protection des données critiques de la CMDB
-
Garantir la disponibilité du service en cas d’incident majeur
-
Définir une perte de données acceptable (RPO)
-
Définir un temps de coupure toléré (RTO)
-
Mettre en place une stratégie de sauvegarde fiable et sécurisée
-
Respecter la règle de sauvegarde 3-2-1 pour assurer la résilience des données
-
Garantir la traçabilité et l’imputabilité des actions via des comptes nominatifs
-
Sécuriser les accès aux opérations de maintenance et de sauvegarde
-
Vérifier et valider la fiabilité des sauvegardes par des tests de restauration
-
Assurer la continuité d’activité en cas de panne, perte ou cyberattaque
Solution technique retenue :
La solution technique retenue consiste à mettre en place un système de sauvegarde complet du serveur GLPI en combinant la sauvegarde de la base de données et du système de fichiers. La base de données est extraite à l’aide de l’outil mysqldump, garantissant une sauvegarde logique complète des données (tickets, inventaire, configurations), tandis que les répertoires critiques sont archivés à l’aide de la commande tar avec compression.
Afin de garantir la sécurité et l’imputabilité, un compte de maintenance MariaDB dédié est créé avec des privilèges restreints, conformément au principe du moindre privilège. Les identifiants sont stockés de manière sécurisée dans un fichier my.cnf, évitant toute exposition dans les scripts.
Le processus est industrialisé grâce à un script Bash automatisant l’ensemble des opérations (sauvegarde SQL et fichiers), avec gestion des erreurs et génération de logs pour assurer la traçabilité. La planification des sauvegardes est réalisée via Cron, permettant une exécution régulière et respectant les objectifs de RPO.
La gestion de la rétention des sauvegardes est assurée par logrotate, qui permet de contrôler le nombre de versions conservées et d’éviter la saturation du stockage.
Enfin, des vérifications du contenu des archives sont réalisées afin de garantir leur intégrité, et la solution est validée par des tests de restauration complets permettant de vérifier la cohérence des données et le respect du RTO. Cette approche s’inscrit dans une logique de résilience conforme à la règle de sauvegarde 3-2-1.
Script de sauvegarde automatisé :
Pour automatiser le processus de sauvegarde, un script Bash a été développé. Ce script est le suivant :
#!/bin/bash
# =====================================================================
# NOM : backup_solutech.sh
# ROLE : Automatisation de la sauvegarde (SQL + Filesystem)
# AUTEUR : Vicky
# =====================================================================
# 1. DÉFINITION DES VARIABLES
DATE=$(date +%F_%H-%M)
DEST="/home/servglpi/backups"
DB_NAME="glpidb"
LOG_FILE="/var/log/backup_solutech.log"
# Liste des dossiers à archiver
SRC_GLPI="/var/www/html/glpi/files"
SRC_CONFIG="/var/www/html/glpi/config"
SRC_APACHE="/etc/apache2/sites-available"
# 2. PRÉPARATION
mkdir -p $DEST
chown servglpi:servglpi $DEST
echo "--- DÉBUT DE LA SAUVEGARDE : $DATE ---" >> $LOG_FILE
# 3. SAUVEGARDE SQL (Utilise ~/.my.cnf automatiquement)
mysqldump $DB_NAME --single-transaction > $DEST/dbglpi.sql
if [ $? -eq 0 ]; then
echo "[$DATE] SUCCESS: Dump SQL réalisé avec succès." >> $LOG_FILE
else
echo "[$DATE] ERROR: Échec du dump SQL. Vérifiez les droits." >> $LOG_FILE
exit 1
fi
# 4. SAUVEGARDE DES FICHIERS (Archivage compressé)
tar -czf $DEST/glpi_config_files.tar.gz $SRC_GLPI $SRC_CONFIG $SRC_APACHE
if [ $? -eq 0 ]; then
echo "[$DATE] SUCCESS: Archivage des fichiers terminé." >> $LOG_FILE
else
echo "[$DATE] ERROR: Échec de l'archivage." >> $LOG_FILE
exit 1
fi
echo "--- FIN DE LA MISSION ---" >> $LOG_FILE
Travail réalisé :
-
Identification des éléments critiques du système GLPI (fichiers, configuration, base de données)
-
Réalisation de sauvegardes du système de fichiers avec tar (compression et nommage automatisé)
-
Vérification de l’intégrité des sauvegardes (taille et contenu des archives)
-
Analyse des fichiers de configuration pour identifier la base de données et les accès
-
Sauvegarde de la base de données avec "mysqldump"
-
Création et utilisation d’un compte de maintenance MariaDB avec privilèges restreints
-
Exploration et validation de la base de données via des requêtes SQL
-
Sécurisation des identifiants via un fichier ".my.cnf"
-
Développement d’un script Bash automatisant les sauvegardes (SQL + fichiers)
-
Mise en place de logs et gestion des erreurs pour assurer la traçabilité
-
Configuration de Logrotate pour gérer la rétention des sauvegardes
-
Planification automatique des sauvegardes avec Cron
-
Vérification du bon fonctionnement de l’automatisation via les logs
-
Simulation d’un incident majeur (perte base + fichiers) et restauration complète du système à partir des sauvegardes
-
Validation du service après restauration (intégrité et disponibilité des données)
-
Application de la règle de sauvegarde 3-2-1
Résultats :
La mise en place de cette solution a permis de sécuriser efficacement les données critiques du serveur GLPI, en garantissant la disponibilité et la protection du patrimoine informationnel de l’entreprise. Les sauvegardes sont désormais réalisées de manière automatique, fiable et régulière, limitant fortement les risques de perte de données.
L’industrialisation du processus via un script Bash et une planification avec Cron a permis de supprimer les interventions manuelles, réduisant ainsi les erreurs humaines et assurant le respect des objectifs de RPO. La gestion de la rétention avec Logrotate garantit un stockage maîtrisé, évitant toute saturation du serveur.
La sécurisation des accès grâce à un compte de maintenance dédié et au fichier .my.cnf renforce la protection du système tout en assurant la traçabilité des actions réalisées.
Enfin, les tests de restauration ont permis de valider la fiabilité des sauvegardes et la capacité à restaurer rapidement le service en cas d’incident. Le temps de reprise (RTO) a été respecté et l’intégrité des données vérifiée, assurant ainsi le maintien en condition opérationnelle (MCO) et la continuité d’activité de l’entreprise.
Preuves de réalisation :
Voici une capture d'écran du résultat de la commande de vérification pour mon archive config avec la présence du fichier config_db.php:
Nous voyons que l'archive est complète.
Ensuite, voici une capture d'écran du résultat de mes commandes mysqldump et ls -lh pour observer la création d'un nouveau Backup et vérifier l'imputabilité de l'action :
A présent, voici une capture d'écran de ma reqête SQL qui vérifie la présence de mon compte de maintenance (sauvegarde) et de son mot de passe hashé dans la base de données :
Voici maintenant une capture d'écran du résultat de mon script de sauvegarde automatisé, avec la création de nouvelles archives, ainsi que la génération d'un fichier de log :

Pour continuer, voici une capture d'écran qui montre le bon focntionnement de Logrotate, avec la création d'une nouvelle archive et la suppression de l'ancienne :

Pour démontrer le bon fonctionnement de la planification des sauvegardes avec Cron, voici une capture d'écran du résultat de la commande crontab -l qui affiche la planification de mon script de sauvegarde :

Enfin, voici une capture d'écran des évenements dans le fichier event.log$ de GLPI, qui montre une connexion, ensuite une impossibilité de se connecter (suite à la simulation avec la perte de la base de données) et enfin une connexion réussie après la restauration du système à partir des sauvegardes :
